NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c++-part2/17207

Internet Message Format | 1996-08-05 | 11.2 KB

Path: news.nstn.ca!news
From: [e-mail] (dbshapco)
Newsgroups: comp.lang.eiffel,comp.lang.c,comp.lang.c++,comp.object,comp.software-eng
Subject: Re: OOA [was:Re: Beware of "C" Hackers -- A rebuttal to Bertrand Meyer]
Date: 14 Apr 1996 14:13:26 GMT
Organization: iSTAR Navigator User
Message-ID: <4kr166$[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <4kkkbm$[e-mail]> <[e-mail]> <4kma54$[e-mail]> <[e-mail]>
Reply-To: [e-mail]
NNTP-Posting-Host: ts6-11.ott.istar.ca
Mime-Version: 1.0
X-Newsreader: WinVN 0.93.14

In article <[e-mail]>, [e-mail] says...
>
>Kazimir Kylheku ([e-mail]) wrote:
>
>>The OO arena is a philosophical one. I don't particularly subscribe to the

>>view
>>that there ought to be a naive correspondence between software entities and
>>some ``real world'' entities,  ....
>
>Nor do I.  The (apparently widespread) idea that such correspondence
>is in some way significant to the basis of object-oriented <whatever>
>is, IMO, a gross misconception.  Object technology has a sound basis
>without it, and in programming, one is rarely modelling the "real world"
>directly (except in UI, when building upon spatio-temporal "real world"
>metaphors to bridge the gap between the abstractions a program is
>based on and the user, and even then, the models used are abstract).

Many cooked examples for OO tend to use hyperbolic real world correspondence
which leads people with superficial understanding of OOA to assume that OO
demands modeling 'real world' objects.  In some problem domains this is
possible and convenient, but many problem domains are abtract and have no
real world correspondences.

OOA however should produce a nomenclature and taxonomy for the problem domain
that permits the problem to be described to people sophisticated in the
problem domain but not in software development (violation to this rule is of
course when the problem domain IS software development in some form).  This
step is fundamental to communicating elements of the problem statement from
users to developers using common and accepted terminology (rather than the
jargon of either community) AND to limiting communication to the problem
domain (and NOT the solution domain -- that is, how the problem is solved
using software).

Since sound SE demands high traceability through analysis, design,
implementation and even testing (OO or NOT), the nomenclature and taxonomy
should appear in later stages of software development.  One should be able to
pick out an entity in the analysis and trace through to see how it affected
design and implementation, or conversely to pick a piece of implementation
and trace up through design to the analysis that motivates that software.
IME, A&D aren't much worth pursuing when they do not produce traceability.
(The A&D then are practically throw-away, and little use to enhancing and
maintaining the software.)

The largest problem I see in SE A&D (and we still aren't speaking
specifically to OO) is using A&D as alternate ways of describing
implementation.  There is very little value in this and it is often
frustrating to developers who in fact end up producing descriptions of the
same thing several times, only the last of which compiles.  (As with most
things the strongest criticisms for A&D and OO and OOA&D seem to arise from
misunderstanding and abuse, rather than inherent flaws.)  This improper level
of abstraction also leads to throw-away A&D, because it is IMPOSSIBLE to
synchronize a high-level description of an implementation with an actual
implementation.

(As this suggests, it is possible to commit or learn to OO in stages,
although it would seem to be easier to start with analysis and move to
implementation, while unfortunately most practioners go through the reverse
and pick up bad habits along the way.)

Now back to OO.  Given that the developer (or even better, a domain
specialist) has produced a sound analysis of the problem domain, it is fairly
straightforward to move through OOD and OOP by converting the nomenclature
and taxonomy into classes and a class hierarchy.  The problem, as mentioned
earlier, is getting a good nomenclature and taxonomy that describes the
problem domain.  If there is no real world correspondence that suggests a
decomposition of the problem domain, then conventions from the problem domain
or any appropriate metaphor can be employed (most problem domains have
conventional terminology to describe 'entities' in that domain -- finding a
good metaphor is more challenging and might even require a degree of
imagination and creativity in the analyst).  A common metaphor, as mentioned
by the previous poster, is 'windows' in the GUI domain (although most
metaphors used in software are far from pure -- what has a 'mouse' to do with
'windows', and how did 'menus' get mixed up with either!).

Two problems seem to appear here.  First, entities from the solution domain
appear in an analysis of the problem domain, caused by anticipation (the
analyst is subconsciously solving the problem domain in her head even as she
analyses it), wrong expertise (using developers with high knowledge of the
solution domain and low knowledge of the problem domain to perform analysis),
and re-engineering (the problem and solution domains are so interwoven in
legacy software that they are difficult to differentiate), or recursion (the
problem domain is connected somehow with software engineering or
development, and so it is difficult to separate terminology from the problem
domain and solution domain -- most often the concept of META-languages or
META-models becomes employed to differentiate the domains).  Second, when
metaphors must be used in analysis, the analyst becomes obsessed with the
metaphor and detaches from the problem domain (this problem seems most common
to people who deal mostly in abstract domains, or have a tendency to try to
make the world fit their aesthetically pleasing theoretical models --
symptomatically the analyst goes looking for something in the problem
domain to correspond to some term suggested by the metaphor).

A naive and simplistic approach to *forcing* problem domains to be described
in terms of unrealistic real world correspondences is wrong, and adds nothing
to software engineering.  It may be easy to derive classes and a class
hierarchy from such an analysis, but it won't aid understanding or
communication of the problem or its solution.  Such misapplication of OOA I
think results most often in criticism of OOA (and then when the poorly
thought out classes and class hierarchy are converted to implementations, OOP
et criticized for being puerile and simplistic).

In a nutshell, any anticipation of the solution domain pollutes analysis, to
the worst case in which analysis is nothing more than an alternate way of
describing implementation (ditto design).  OOP should generate objects which
correspond to entities in the problem domain and the relationships suggested
by a well defined taxonomy, and the quality of the classes and class
hierarchy vary directly with the quality of analysis.  Puerile and
simplisitic analysis based on inappropriate or forced correspondences usually
results in crippled and incomprehensible classes and class hierarchies.

--

Brad Shapcott
Lockheed-Martin's Advanced Concepts Center, Ottawa, Canada
Ph: [phone] x227 1-800-43-TRAIN

[If some junk follows this signature, pls e-mail me -- this is the first time
I've used this particular posting program.]
; winvn.ini
[Personal]
UserName=dbshapco
MailAddress=[e-mail]
Organization=iSTAR Navigator User
ReplyTo=[e-mail]
[Communications]
UseSocket=1
NNTPHost=news.nstn.ca
SMTPHost=fox.nstn.ca
NNTPService=nntp
MailDemandLogon=1
MailForceType=2
DebugComm=1
GenSockDLL=genasync.dll
ConnectAtStartup=1
[Authorization]
NNTPUserName=
NNTPPassword=
NNTPSavePassword=0
[Preferences]
EnableThreading=1
SignatureFile=C:\NAVIGATR\NEWS\WinVn.ini
EnableSignature=1
MailLog=0
MailLogFile=MAIL.LOG
PostLog=0
PostLogFile=POST.LOG
DoList=2
FullNameFrom=1
ArticleThreshold=50
ShowUnsubscribed=1
ShowReadArticles=1
ConfirmBatchOps=1
NewWndGroup=1
NewWndArticle=0
SaveArtAppend=1
ConnectAtStartup=1
ConfirmExit=1
ConfirmReplyTo=1
CcByMail=0
ThreadFullSubject=0
GroupMultiSelect=0
ShowUnreadOnly=0
[Coding]
CodingStatusVerbose=0
DumbDecode=0
ArticleSplitLength=50000
EncodingTable=
SubjectTemplate=%s  -  %f [%p/%t]
MIMEBoundary=*-*-*- Next Section -*-*-*
BlankBeforeMIME=0
DecodePath=C:\NAVIGATR\NEWS\download
BlockCodingStatusAlwaysOnTop=0
ReviewAttach=1
AttachInNewArt=0
ExecuteDecodedFiles=0
KeepArticleHeaderVisible=0
UseSmartFiler=1
EncodingType=Base-64
GenerateMIME=1
MIMEUsageSuggestions=1
MIMEUUType=x-uue
MIMEXXType=x-xxe
MIMECustomType=x-custom3to4
DefaultContentType=Other
AlsoDecodeOpenArticles=0
MinimizeStatusWindows=0
[Interface]
ListFontFace=Courier
ListFontSize=10
ListFontStyle=Regular
ArticleFontFace=Courier
ArticleFontSize=10
ArticleFontStyle=Regular
StatusFontFace=Times New Roman
StatusFontSize=11
StatusFontStyle=Regular
PrintFontFace=Arial
PrintFontSize=12
NetUnSubscribedColor=0,0,200
NetSubscribedColor=0,0,0
ArticleUnSeenColor=0,0,0
ArticleSeenColor=0,0,200
ArticleTextColor=0,0,0
StatusTextColor=0,0,0
ArticleBackgroundColor=255,255,255
ListBackgroundColor=255,255,255
StatusBackgroundColor=255,255,255
ThumbTrack=1
WinVnFontFace=MS Sans Serif
WinVnFontSize=8
WinVnFontStyle=Bold
CompositionFontFace=Courier
CompositionFontSize=10
CompositionFontStyle=Regular
UseInverseSelections=0
[winvn]
Notice1=**** The [winvn] section is no longer needed unless    ****
Notice2=**** you want compatibility with old versions of WinVn ****
[Admin]
Newsrc=C:\NAVIGATR\NEWS\NEWSRC
Version=WinVN 0.93.14
[Searches]
LastArticleTextFind=
LastArticleHeaderFind=
LastGroupNameFind=
[Smart Filer]
OnDupeName=0
OnNameTooLong=0
MaxFileNameLen=8
MaxFileExtLen=3
EnableExtensionConversion=1
[Mail Addresses]
Address1=[e-mail]
[Logging]
MailLog=0
MailLogFile=MAIL.LOG
PostLog=0
PostLogFile=POST.LOG
[Confirmation]
ConfirmBatchOps=1
ConfirmDisconnect=0
ConfirmSaveOnExit=0
ConfirmReplyTo=1
[Group List]
DoList=2
ShowUnsubscribed=1
GroupListMultiSelect=0
UsenetWindowPos=0,0,400,540
[Article List]
ArticleThreshold=50
MinArticlesToRetrieve=50
FullNameFrom=0
EnableThreading=1
ShowUnreadOnly=0
NewWndGroup=0
ThreadFullSubject=0
ThreadDepthIndicator=
SaveArtAppend=1
ArtListMultiSelect=1
GroupWindowPos=1,0,800,300
[Article]
NewWndArticle=0
WrapIncomingArticleText=0
WrapIncomingArticleTextLength=80
TrimHeaders=1
ScrollPastHeaders=1
ItalicizeQuotes=1
ArticleWindowPos=130,259,640,362
[Compose]
WordWrap=1
PrefillCcAddress=1
ShowOrgHdr=0
ShowReplyToHdr=0
ShowKeywordsHdr=0
ShowSummaryHdr=0
ShowDistributionHdr=0
ShowFromHdr=0
FollowupSaysTemplate=In article %i, %a says...
ReplySaysTemplate=In article %i, you say...
SignatureFile=C:\NAVIGATR\NEWS\WinVn.ini
EnableSignature=1
[Attachments]
DefaultAttachInNewArt=0
ArticleSplitLength=50000
SubjectTemplate=%s  -  %f [%p/%t]
GenerateMIME=1
MIMEUsageSuggestions=1
MIMEBoundary=*-*-*- Next Section -*-*-*
MIMEUUType=x-uue
MIMEXXType=x-xxe
MIMECustomType=x-custom3to4
DefaultEncodingType=Base-64
DefaultContentType=Other
EncodingTable=